Every RFP for a new MES rollout now has an “edge” line item, and half the time the person writing it can’t quite define what belongs there. That’s not a knock on anyone — the category genuinely didn’t exist in its current form a few years ago. Historically you had PLCs, a historian, maybe an OPC server, and a chunky integration project to stitch it into MES. Now Siemens, Rockwell, and a growing list of independent players are all selling something called an edge platform, and they mean noticeably different things by it. That ambiguity is exactly why plant engineers keep getting burned: they buy an edge tier expecting it to reduce integration work, and instead it becomes a new layer of vendor-specific tooling sitting between the machine and the systems that actually need the data.
The fix is to stop evaluating “edge” as a marketing category and start scoring it against the things that actually determine whether a deployment goes smoothly. Below is the checklist worth applying, and a read on how four platforms — Siemens Industrial Edge, Rockwell FactoryTalk Edge, HiveMQ Edge, and Litmus — stack up against it in general terms.
What actually belongs on the scorecard
Five criteria separate a genuinely useful edge layer from an expensive pass-through box.
Protocol and controller support
Can it talk to what’s actually on your floor — OPC UA, Modbus, Ethernet/IP, plus the vendor-specific dialects of PLCs that predate any of this tooling — or only to its own family’s hardware cleanly, with everything else requiring a third-party driver or custom connector? This matters more than any other line item on the list, because a brownfield plant with mixed-vintage equipment lives or dies on driver coverage.
Offline buffering and store-and-forward
Networks drop. The question is what the edge node does when the WAN link to MES or the cloud goes down: does it buffer locally and replay in order once connectivity returns, does it silently drop data, or does it just stop and wait for someone to notice? For anything feeding OEE, genealogy, or compliance records, store-and-forward isn’t a nice-to-have, it’s the whole point of putting compute at the edge in the first place.
Container and update cadence
Most of these platforms are now built around containerized apps — Docker or similar — running on an edge device or industrial PC. That’s good in principle: you can version, roll back, and push updates without touching the control network directly. But it also means you’ve taken on a container lifecycle to manage, patch, and secure, on top of everything else plant IT already owns. Ask how updates are staged, whether there’s a rollback path, and who’s accountable when a container update breaks a running connector.
Licensing model, especially per-tag or per-connector pricing
This is where edge platforms quietly become expensive. Per-tag licensing, per-connector fees, or per-node subscription tiers can make a pilot look cheap and a plant-wide rollout look very different. Get the vendor to walk through cost at your actual tag count and node count before you fall in love with the demo.
Unified Namespace publishing
If you’re building toward a UNS — a single, event-driven source of truth typically brokered over MQTT with Sparkplug B payloads — the edge layer’s job is to normalize disparate protocols into that namespace cleanly, not to become its own competing namespace. Some platforms do this natively. Others treat MQTT as one more output option bolted onto a proprietary core, which works but leaves you doing more mapping than you’d like.
How the four stack up
Siemens Industrial Edge
Siemens built this around its own device and app-management ecosystem, with strong native support for Siemens controllers and a growing app catalog from Siemens and third parties. In our assessment, it’s a strong fit for plants that are already heavily Siemens on the automation layer — the integration with S7 controllers and TIA Portal workflows is genuinely tight. Where it may suit less well is in a mixed-vendor shop: connectivity to non-Siemens controllers is supported but tends to require more deliberate setup, and shops should weigh how much of the value depends on staying inside the Siemens ecosystem versus treating it as protocol-neutral infrastructure.
Rockwell FactoryTalk Edge
Rockwell’s edge story leans on its existing FactoryTalk stack and deep familiarity with Logix controllers, which is its clearest advantage for Allen-Bradley-centric plants. The tradeoff is similar to Siemens’: the deeper the native integration with one automation vendor’s hardware, the more a buyer should ask what happens at the boundary with everything else on the floor — third-party PLCs, older Modbus devices, sensors that never spoke Ethernet/IP to begin with. For a single-vendor Rockwell shop planning an MES buildout, it’s a reasonable default to shortlist. For a multi-vendor brownfield site, it’s worth pressure-testing driver coverage before committing.
HiveMQ Edge
HiveMQ comes from the MQTT broker world rather than the automation-controls world, and it shows: this is a lighter-weight, protocol-normalization-first tool built to bridge OT protocols into MQTT and Sparkplug B with minimal ceremony. That makes it a strong fit for teams already committed to a UNS architecture who want an edge layer that does one job — translate and publish — rather than a full application platform. It may suit less well as a standalone answer for teams that also want built-in analytics apps, device management fleets, or a vendor-managed container marketplace; HiveMQ Edge is deliberately narrower in scope, and pairing it with other tooling for those functions is part of the design, not a gap to hold against it.
Litmus
Litmus positions itself as vendor-agnostic middleware with a strong emphasis on broad protocol/driver support and analytics at the edge, aimed squarely at brownfield environments with mixed PLC populations. In our assessment, that’s its best-fit case: a plant with a genuine mess of controller vintages and brands, where the priority is normalizing everything into a common data model before it hits MES or a UNS. It may suit less well organizations that are already single-vendor on automation and would rather stay inside that vendor’s own tooling and support relationship.
The pattern underneath the pattern
Notice the shape of the tradeoff repeating across all four: platforms built by automation vendors integrate beautifully with that vendor’s own controllers and less effortlessly with everyone else’s. Platforms built by independent or MQTT-native vendors integrate more evenly across brands but ask you to assemble more of the surrounding stack yourself. Neither approach is wrong. The mistake is picking based on the demo instead of based on which side of that tradeoff actually matches your floor.
Before shortlisting anything, get honest answers on four things: your actual controller/protocol mix, whether you’re building toward a UNS or a point-to-point integration, your real tag count at full scale (not pilot scale), and who on your team will own container updates and driver maintenance long-term. Run that against the checklist above, and the RFP writes itself — instead of the vendor writing it for you.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
